Constraints in an Object-Oriented Deductive Database

approximation sequences are easier to generate because the cost of the abstract computation is independent from the database size. However, this is still a sound and complete procedure: Theorem [Ca91b]: A completed database instance v is a solution of (d0, C) iff there exists an abstract approximation sequence (d i) such that dn = v. We can also define abstract fixpoint approximation sequence, which will converge faster (there is a smaller set of abstract fixpoint approximation sequences) but with a high complexity of computation (computing Y(ε#) is more complex). 4.2 Lazy Evaluation vs. Propagation In the next section, we shall describe an algorithm that builds an exhaustive enumeration of abstract computation sequences; thus, it is sound and complete. There are still two freedom degrees upon which the efficiency of the resolution will depend: • Goal ordering: some problems (for instance, the n-queens with a large number of queens [VH89]) demand the application of the firstfail principle, which states that the goal with the smallest domain should be tried first; some other problems, such as placement problems, hold a better order derived from the object topology. • Balance between propagation and evaluation: each constraint can be evaluated lazily just before a value is chosen for a goal, or it can be propagated so as to maintain the domains for all goals as soon as any hypothetical assignment is made. The previously mentioned first-fail principle requires some propagation so that the choice made according to cardinality is significant. In this paper we describe an algorithm that uses the first-fail principle because we have found it to be the more commonly useful, but we have also used some variations (other orders) for other problems such as [GGN90]. The cardinality of each goal (R i,x i) is the cardinal of the abstract set d#(R i)(x i). Those sets will be maintained by active propagation because of the following. • Active constraints: each constraint has a mode, that is either specified by the user or inferred from some general declarations. A constraint can be lazy (it will be used with a ε -reduction step at the "last minute"), abstract-lazy (it will also be used at the last minute for a ε# reduction step), or act ive . When a constraint is active, the abstract sets are dynamically reduced so that the current database instance is a fixpoint for the ε# reduction function associated to this constraint. • Negative constraints can be lazy or active. When a negative constraint is active, the negative constraint is implemented as an abstract propagation rule (cf. Section 3.3). Active constraints or propagation rules rely on the ability to efficiently propagate an update in the database. We need to know which new pairs satisfy a rule condition (an algebraic term) when an update R i( a , b ) is made. As was noticed in [FU76] and detailed in [PS77], incrementally computing a set of objects satisfying a given specification is analogous to mathematical differentiation. Differentiation rules have been developed for database relational algebra ([BR86] or [SKGB87]). A nice property of this relational algebra (A (R)) is that differentiation can be introduced as a higher-order operation [Ca91a]. If we define the induced functional algebra F(R1 ,..., Rn) as A(0,1,R1 ,..., R n), where 0 and 1 are reserved names , each term ƒ of this algebra represents a function from O × O to P(O × O) for each database instance d . By extension, we write this function d(ƒ), which is defined by: ∀ o1,o2 ∈ O, d(ƒ)(o1,o2) = d(ƒ) in A(0,1,R1 , ..., Rn), where d(0) = ∅ , d(1) = {(o1,o2)) and ∀ i, d(R i) = d(Ri) The key property of this algebra is the existence of a formal operation ∂/∂ called differentiation on A (R) × R → F (R), defined by formal rules. We write ∂t/∂Ri for the differentiate of the term t according to R i.The interest of differentiation holds in this result: Theorem: • ∀ d ∈ D, ∀ Ri ∈ R, ∀ (o1,o2) ∈ O × O, ∀ t ∈ A(R), if (o1,o2) does not belong to d(Ri) and if we define a database instance d' by d'(Ri) = d'(Ri) ∪ {(o1,o2)) and d'(Rj) = d'(Rj) for all other j: d ' ( t ) = d(t) ∪ d'(∂t/∂Ri)(o1,o2) • ∂ t / ∂ R i is the smallest term from F (R) which satisfies the previous equation (any other similar term represents a function that always contains ∂t/∂R i) . The idea of differentiation can be found in the RETE algorithm [Fo82], where it is a graph operation, or for relational databases, where it is defined by a database computation [BR86]. In this model, we obtain a f o r m a l differentiation (on abstract functions instead of database instances), which provides a better implementation. More details and correctness proofs may be found in [Ca91a]. As explained in [Ca89], the differentiated terms can be in turn compiled into efficient low-level functions. 4.3 Resolution Algorithm We shall now describe a resolution algorithm that produces one (possible) solution to a set of constraints, rules, and production rules. The first step is to compute an approximation of the fixpoint, using the abstract interpretation. We then start the enumeration of all completions, using the first-fail principle. The propagation is based on two operations: • The function obtained by di f ferent ia t ion , ∂ T / ∂ R i(x ,y) , returns the exact set of pairs that appears in d(T) when (x,y) is added in d(R i) (cf. previous section). • Similarly ∂ #T / ∂ R i(x ,S) returns a set of pairs (x ' ,S ') where S' is an abstract interpretation of d(T)(x') , which uses the new value S given to d(R i)(x) . Notice that this is just a convenient notation (there is no "differentiation" with abstract interpretation since we must have S' = d#(T)(x') because the new value S is not a positive update). We use an exception-handling mechanism described in [Don90], which catches contradictions raised either by the detection of an empty set of possible values or the violation of an integrity constraint. We may now describe the algorithm (the database instance d, the constraints, rules, and production rules are global resources), which solves a list of given goals. The resolution algorithm [Ca91c] uses two steps: Predict(L) and Enumerate(L). Predict(L) computes (semi-naive iteration) the fixpoint Y(ε#) [Ca91b] for the goals in L. We apply each reduction step (ε#) for each relevant rule until no further reduction can be performed. Enumerate(L) builds all the possible approximation sequences using a ε -reduction step for lazy constraints, a ε#-reduction step for abstract lazy constraints and a Y(ε#) reduction step for active constraints. The backtrack mechanism relies on the ability to make copies of the database and return to previously stored states. Fortunately, this is supported efficiently in the LAURE system [Ca91a]. Whenever a new fact R i(x,y) is obtained (for instance, a choice R i(x) = y is made by the constraint solver), it is propagated using differentiation to activate all relevant production rules and using the abstract computation to reduce the domains of the current goals. This algorithm is sound and returns one possible solution. With a minor modification, we can use it to build the set of all solutions. The completeness relies on the fact that the algorithm builds all computation sequences because of the respective properties of abstract interpretation and differentiation. Since solutions are complete computation sequence by definition, the result follows. Notice that because of the characterization of Section 3.1, a corollary is that the algorithm finds the exact set of all solutions for a "pure" constraint problem(d0, C) with no production rules. The implementation has been described in other papers [Ca89,91a] with more details. Here we just give some principles, that may explain some of the good results that will be presented in the next section. Each rule or constraint is transformed into an equivalent algebraic form which holds no logic variables and can be compiled into low-level (C) code. The ability of direct procedural compilation is one great advantage of combinatoric logic. The translation is performed before run-time, and the algebraic form is actually the representation of an imperative computation. The practical application of this property is presented in [Ca89], which shows how compiled demons are produced from logical rules. Each rule, axiom or constraint is actually stored as a set of equivalent demons, stored in the demon attributes of the relations. The logic language L3 is implemented as an extension of the LAURE programming language. Resolution algorithms are just reduced to triggering the right compiled functions, with very little overhead, and the unification (top-down) or pattern-matching (bottomup) work is entirely performed during the compilation. The current implementation uses LAURE's own main-memory object management. This makes LAURE a deductive database language rather than a true database. However, we have tried large problems using virtual memory and obtained good results (task assignment problems, large transitive closures). We believe that our resolution techniques are well suited for a large volume of information. The main reason is the tight coupling with the object-oriented model, which supports the efficient handling of a large domain through set organization. Our current work is to use C++ as a common object layer, to interface LAURE with a commercial OODBMS. This will add persistency to LAURE objects and complete our database system.